The Wireless Application Protocol (WAP) defines an industry-wide specification for developing applications that operate over wireless communication networks. The scope for the WAP Forum is to define a set of specifications to be used by service applications. The wireless market is growing very quickly, and reaching new customers and services. To enable operators and manufacturers to meet the challenges in advanced services, differentiation and fast/flexible service creation WAP Forum defines a set of protocols in transport, security, transaction, session and application layers.
The Security layer protocols in the WAP architecture can be the Wireless Transport Layer Security (WTLS) or the standard Transport Layer Security (TLS) Internet protocol. WTLS provides functionality similar to TLS but is more adapted to lower bandwidth communication channels. TLS and WTLS layer operate above the transport protocol layer. They provide the upper-level layer of WAP with a secure transport service interface and also provide an interface for managing (eg, creating and terminating) secure connections. The primary goal of the WTLS or TLS layers is to provide privacy, data integrity and authentication between two communicating applications.
For optimum security, some parts of the security functionality need to be performed by a tamper-resistant device, so that an attacker cannot retrieve sensitive data. Such data is especially the permanent private keys used in the WTLS or TLS handshakes with client authentication, and for making application level electronic signatures (such as confirming an application level transaction).
In particular, when a message has to be hashed in a mobile coupled to a WIM module, all the blocks are transferred from the mobile to the WIM for being hashed. Then, the WIM sends the result to the mobile. An example of a WIM implementation is the smart card CAR. In the phone, it can be the Subscriber Identity Module SIM card or an external smart card. The problem is that, in the WIM, resources are very limited; consequently, calculations take a lot of time.
For example, in WTLS and TLS, the Mobile Equipment sends to the server a message called “Finished” message, which is always sent to the server at the end of a handshake to verify that the key exchange and authentication processes were successful between the mobile and the server. The Mobile Equipment uses the smart card for calculating the data to send in the “Finished” message and also the data that should be received from the server. In order to do that, the mobile ME issues the “Client Finished Check” and “Server Finished Check” commands to the smart card CAR. Using a Pseudo Random Function (PRF), the smart card calculates a requested number of bytes based on the session master secret, and a seed value received from the mobile. The card then returns the bytes to be used by the mobile in the “Finished” message. For calculating the Client Finished Check data, the mobile uses a primitive called WIM-PHash primitive with the following input data parameter:“client finished”+Hash(handshake_messages)
The “Hash(handshake_messages)” is defined as the SHA-1 and/or MD5 hash (depending on protocol) of the concatenation of all previous handshake messages that were exchanged up to but not including the “Finished” message. The primitive then returns to the mobile the needed data block.
We will refer the standard for more details about the commands and primitives which are cited above.
In the same manner, for Calculating the server finished check, the mobile ME uses the WIM-PHash primitive with the following input data parameter:“server finished”+Hash(handshake_messages).
The primitive then returns to the mobile the needed data block.
In SSL, the parameters that are sent to the WIM for the “Finished” message are different. When we perform the finished check in SSL, it is necessary to perform a hash on:‘handshake_messages+Sender+master_secret+pad1’.Comparing with WTLS and TLS, we see that the Hash should be calculated also over the session “master secret” in addition to “handshake_messages”. This poses a problem since the mobile ME does not know the value of the master secret as it is securely stored in the smart card CAR and is never exposed externally. Consequently, the following data: ‘handshake_messages+Sender+master_secret+pad1’ has to be sent to the WIM for being hashed. Nevertheless, resources are very limited in the WIM, consequently calculations in the smart card take a lot of time.